home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / tsql / doc / tdbglossary.mail / 000010_ahn@cbnmva.att.com _Fri Sep 10 13:29:05 1993.msg < prev    next >
Internet Message Format  |  1996-01-31  |  6KB
  1. Received: from univers.CS.Arizona.EDU by optima.CS.Arizona.EDU (5.65c/15) via SMTP
  2.     id AA25866; Fri, 10 Sep 1993 13:29:06 MST
  3. Date: Fri, 10 Sep 1993 13:29:05 MST
  4. From: ahn@cbnmva.att.com
  5. Message-Id: <199309102029.AA03984@univers.cs.arizona.edu>
  6. Received: from att.UUCP by univers.cs.arizona.edu; Fri, 10 Sep 1993 13:29:05 MST
  7. To: tdbglossary@cs.arizona.edu
  8. Subject: Re: DEADLINE FOR ...
  9.  
  10. Greetings,
  11. I have been out of town for some weeks, so could not send the
  12. following comments before the deadline.
  13. (Or is this earlier enough for the November 4 deadline ?)
  14. If it is too late, I hope these can be considered in the next version.
  15.  
  16. I feel that some of these are rather significant (e.g. P1, P2, P6), but
  17. may easily be incorporated in the final version.
  18. I group them into two categories, one for changing some terms
  19. and the other for minor adjustments.
  20.  
  21. * Proposals for changing some terms:
  22.  
  23. P1:    User-defined Time (Section 3.3)
  24.     problem:    User-defined time can easily be confused with
  25.             the feature for the user-defined data types,
  26.             as described in the next entry for
  27.             "Temporal Data Type".
  28.         It seems to suggest a new data type defined by users
  29.             to handle time.
  30.         This was not much of a problem before, but it will become so
  31.             when the user-defined data types become available
  32.             e.g. in SQL3.
  33.         (I think I, with Rick, am partly responsible for this misnomer)
  34.     replacing term:
  35.     User-dependent Time
  36.         The semantics of user-dependent time is dependent upon
  37.             user's interpretation, and not interpreted
  38.             by the system.
  39.         This avoids the confusion with the user-defined data types.
  40.  
  41. P2:    Temporal Element (Section 3.15)
  42.     problem:    This term is not intuitive, in fact counter-intuitive,
  43.             for representing a union of time intervals.
  44.         It sounds like an elementary item, e.g.
  45.             a single timestamp or a chronon.
  46.         Besides, \part{Previously Used Names} mentions
  47.             the same term again.
  48.     replacing term:
  49.     "Multi-intervals" or "Interval sets" or simply "Intervals"
  50.         I personally prefer "Multi-intervals", but anything
  51.             would be better than "temporal element".
  52.  
  53. P3:    Beginning (Section 4.25)
  54.     problem:    too vague when there is a better term.
  55.     replacing term:
  56.     Epoch
  57.         Epoch, I think, is the perfect term for this purpose.
  58.  
  59. P4:    Time-invariant Attribute (Section 4.35)
  60.     problem:    too long (-E2) when there is a better and shorter term.
  61.     replacing term:
  62.     Static
  63.  
  64. P5:    Time-variant Attribute (Section 4.36)
  65.     problem:    too long (-E2) when there is a better and shorter term.
  66.     replacing term:
  67.     Dynamic
  68.  
  69. P6:    Predictive (Section 4.41)
  70.     problem:    Term "proactive" is existing and accepted (-E7).
  71.         "proactive" is orthogonal to "retroactive" (-E1).
  72.         Term "predictive" is not precise (-E8).
  73.         Tuples inserted into a predictive bitemporal relation
  74.             instance are not just predictions about the future,
  75.             because predictions are different from facts.
  76.         Rather, such tuples represents facts that would become
  77.             effective in the future.
  78.         "Predictive" means that it may not be quite correct.
  79.     replacing term:
  80.     It is true that "proactive" is not in some dictionary, but
  81.         the term is commonly used.
  82.     Term "proactive" has been existing and accepted (+E7).
  83.     Meanings of "predictive" and "proactive" are different.
  84.     "proactive" is orthogonal to "retroactive" (+E1).
  85.  
  86. P7:    Degenerate Bitemporal Relation (Section 4.42)
  87.     problem:    Term "Degenerate" denotes something unusual or irregular.
  88.         Term "Degenerate relation" may mean a relation
  89.             with no attributes (columns) defined.
  90.     replacing term:
  91.     Synchronous Bitemporal Relation
  92.         If the valid and the transaction times are identical,
  93.             they are synchronous.
  94.         Term "synchronous" is existing and accepted (+E7), and
  95.             precise (+E8)
  96.  
  97. P8:    new entries for Continuous Model of Time
  98. P9:    new entries for Discrete Model of Time
  99.     These are described under "Instant" and "Chronon", but deserve
  100.         separate entries considering their impacts on many aspects.
  101.  
  102. P10:    Retroactive Temporal Relation (Section 4.40)
  103.     Predictive  Temporal Relation (Section 4.41)
  104.     problem:    Terms "retroactive" and "proactive" refers to
  105.             characteristics of an operation, rather than
  106.             a relation which is the result of such an operation.
  107.     replacing term:
  108.     Retroactive Operation
  109.     Proactive Operation
  110.         Define the concepts for the operation, not the relation.
  111.  
  112. * Minor adjustments:
  113.  
  114. A1: Section 3.2 Transaction Time
  115.  
  116.     ~~ database fact is stored in a database at some point in time, and
  117.     ~~ after it is stored, it is current until logically deleted. The {\em
  118.     ~~ transaction time\/} of a database fact is the time when the fact is
  119.                                        ====
  120.                                 >>    becomes
  121.     ~~ current in the database and may be retrieved. Transaction times are
  122.     ~~ consistent with the serialization order of the transactions.
  123.     ~~ Transaction-time values cannot be after the current time.
  124.                          =====
  125.                      >>  later than
  126.  
  127. A2: Section 3.3 Temporal Data Type
  128.     \epart{Definition}
  129.         Temporal data type may be built-in or user-defined.
  130.             (Why or how does it have to be user-defined ?)
  131.  
  132.          ~~ Terms belonging to a user-defined temporal data type
  133.          ~~ get the same query language support as do terms
  134.          ~~ belonging to built-in temporal data types such as the
  135.          ~~ {\tt DATE} data type
  136.  
  137.          Is this true ?
  138.          Isn't this dependent on the query language ?
  139.  
  140. A3: Section 3.24 Event
  141.     \epart{Previously Used Names}
  142.      Event relation, instant relation.
  143.  
  144.         "Event" and "event or instant relation" are of
  145.             different domains, and cannot be compared.